@[TOC](Redis 做分布式锁及Lua 脚本使用)
1. 基本用法
问题场景:在单线程中,一个线程去修改用户的状态,首先从数据库中读出用户的状态,然后在内存中进行修改,修改完成后,再存回去。这个操作没有问题,但是在多线程中,由于读取、修改、存这是三个操作,不是原子操作,所以在多线程中,这样会出问题。
我们可以使用分布式锁来限制程序的并发执行。
原理:分布式锁实现的思路很简单,就是进来一个线程先占位,当别的线程进来操作时,发现已经有人占位了,就会放弃或者稍后再试。
在 Redis 中,占位一般使用 setnx 指令,先进来的线城先占位,线城的操作执行完成后,再调用 del 指令释放位子。
根据上面的思路,我们写出的代码如下:
public class Redis { |
public interface CallwithJedis { |
public class LockTest { |
从 Redis2.8 开始,setnx 和 expire 可以通过一个命令一起来执行了。
2. 解决超时问题
场景:接上文,为了防止业务代码在执行的时候抛出异常,我们给每一个锁添加了一个超时时间,超时之后,锁会被自动释放,但是这也带来了一个新的问题:如果要执行的业务非常耗时,可能会出现紊乱。举个例子:第一个线程首先获取到锁,然后开始执行业务代码,但是业务代码比较耗时,执行了 8 秒,这样,会在第一个线程的任务还未执行成功锁就会被释放了,此时第二个线程会获取到锁开始执行,在第二个线程刚执行了 3 秒,第一个线程也执行完了,此时第一个线程会释放锁,但是注意,它释放的第二个线程的锁,释放之后,第三个线程进来。
对于这个问题,我们可以从两个角度入手:
- 尽量避免在获取锁之后,执行耗时操作。
- 可以在锁上面做文章,将锁的 value 设置为一个随机字符串,每次释放锁的时候,都去比较随机字符串是否一致,如果一致,再去释放,否则,不释放。
2.1 Lua 脚本
对于第二种方案,由于释放锁的时候,要去查看锁的 value,第二个比较 value 的值是否正确,第三步释放锁,有三个步骤,很明显三个步骤不具备原子性,为了解决这个问题,我们得引入 Lua 脚本。
Lua 脚本的优势:
- 使用方便,Redis 中内置了对 Lua 脚本的支持。
- Lua 脚本可以在 Redis 服务端原子的执行多个 Redis 命令。
- 由于网络在很大程度上会影响到 Redis 性能,而使用 Lua 脚本可以让多个命令一次执行,可以有效解决网络给 Redis 带来的性能问题。
在 Redis 中,使用 Lua 脚本,大致两种思路:
- 提前在 Redis 服务端写好 Lua 脚本,然后在 Java 客户端去调用脚本(推荐)。
- 可以直接在 Java 端去写 Lua 脚本,写好之后,需要执行时,每次将脚本发送到 Redis 上去执行。
首先在 Redis 服务端创建 Lua 脚本,内容如下:
if redis.call("get",KEYS[1])==ARGV[1] then |
调用 get 命令,KEYS[1] 表示只有1个,可以n个,下标从1开始;ARGV 除过key之外的其它参数,ARGV[1] 表示只有1个,可以n个。
接下来,可以给 Lua 脚本求一个 SHA1 和(相当于唯一标识符),命令如下:
cat lua/releasewherevalueequal.lua | redis-cli -a javaboy script load --pipe |
script load 这个命令会在 Redis 服务器中缓存 Lua 脚本,并返回脚本内容的 SHA1 校验和,然后在Java 端调用时,传入 SHA1 校验和作为参数,这样 Redis 服务端就知道执行哪个脚本了。
执行完后如下:
接下来,在 Java 端调用这个脚本(代码接上文):
public class LuaTest { |